„Vienota ERP integrācija“ ir standarta solījums, kam praksē seko trīs mēnešu ilgs projekts. Mēs publicējam savu API rokasgrāmatu, lai jūsu IT nodaļa pirms līguma parakstīšanas varētu pārbaudīt, kādi dati faktiski tiek pieprasīti. Šeit ir apkopota informācija, kas jums jāzina pirms integrācijas projekta uzsākšanas.
Ko jūsu ERP sistēmai faktiski ir jānodrošina
Lai izveidotu DPP, mums par katru produktu ir nepieciešams:
- pamatdati - preces numurs, nosaukums, varianti, svars, izmēri, attēli
- detaļu saraksta dati - komponenti ar daudzumiem un otrreizējo izejvielu daļu
- izcelsmes dati - ražošanas vieta, partijas numurs, ražošanas datums
- vides dati - CO2eq uz vienību, ūdens patēriņš, enerģijas patēriņš
- piegādātāju dati - kurš piegādā kādu komponentu (pārbaudes nolūkos)
Teorētiski visi šie dati ir pieejami jūsu ERP sistēmā. Praksē tie ir sadalīti pa 4 līdz 7 moduļiem: materiālu pārvaldība (MM), ražošana (PP), kvalitāte (QM), piegādātāji (LFA1), dažreiz atsevišķs EHS modulis vides datiem, dažreiz PLM sistēma receptūrām.
Integrācijas jautājums nav: «Vai jūsu ERP sistēma sniedz datus DPP?» Tas ir: «Kā jūs apvienojat datus no 5 apakšsistēmām vienā saskaņotā datu kopā?»
Trīs pārbaudīti integrācijas modeļi
1. modelis: OData / REST-Pull
Labi darbojas ar modernām ERP sistēmām (SAP S/4HANA Cloud, Dynamics 365, Odoo). DPP pakalpojuma sniedzējs iegūst datus, izmantojot OData vai REST. Pakāpeniski, plānveidīgi vai notikumu vadīti.
Priekšrocības: neliels attīstības apjoms no jūsu puses, jūs nodrošināt lasīšanas piekļuves datus, pakalpojuma sniedzējs veido transformāciju.
Trūkumi: nedarbojas ar vecākām SAP ECC instalācijām bez papildu API slāņa. Jums ir nepieciešama pārvaldība attiecībā uz datu piekļuves pieprasījumiem.
2. modelis: Notikumu balstīta integrācija
SAP Event Mesh, Apache Kafka, RabbitMQ. Jūsu ERP publicē izmaiņu notikumus, DPP pakalpojuma sniedzējs tos apstrādā.
Priekšrocības: gandrīz reāllaikā, eleganti mērogojams, atdalīts.
Trūkumi: konfigurēšana ir sarežģīta un prasa infrastruktūru, kas nav pieejama katram IT departamentam. Mazākiem uzņēmumiem parasti pārspīlēta.
3. modelis: starpprogrammatūra / ETL
Jums ir integrācijas slānis (Mulesoft, Boomi, Informatica, Azure Data Factory) starp ERP un ārējām sistēmām. Vidusprogrammatūra ir saskarnes slānis - DPP pakalpojumu sniedzējs sazinās ar vidusprogrammatūru, nekad tieši ar ERP.
Priekšrocības: var izmantot esošās investīcijas, pārvaldība ir stabila, trešajām personām nav tiešas piekļuves ERP.
Trūkumi: jūsu starpprogrammatūras izmaksas pieaug proporcionāli sistēmas apjomam.
Kā mēs rīkojamies citādi konkrētos projektos
Daudzi pakalpojumu sniedzēji vēlas tieši savienoties ar jūsu ERP sistēmu. Mēs principā ieviešam starpposmu: mūsu API pieņem neitrālu JSON shēmu, kuru jūs aizpildāt ar jūsu izvēlētu rīku. Tas nozīmē:
- jūs varat veikt datu sagatavošanu paši, izmantojot rīkus, ar kuriem jūsu komanda ir pazīstama
- jūs varat mūs nomainīt - neitrālais formāts ir pārnesams
- jūs jebkurā brīdī varat atgūt visu savu datu krājumu - CSV, XLSX, JSON-LD un SQL formātā, kā arī izmantojot REST-API
- Mēs nodrošinām importēšanas validatoru, kas pārbauda jūsu datus pirms augšupielādes
Pilnā shēma un visi galapunkti ir publiski dokumentēti /apidocs kā OpenAPI specifikācija. Jūsu IT nodaļa var pārbaudīt saskarni pirms līguma parakstīšanas - ieskaitot paraugpieprasījumus, kļūdu atbildes un autentifikācijas datus.
Laika grafiks, izmantojot šo pieeju praksē:
- 1.-2. diena: kartēšanas darbseminārs. Kura ERP lauka atbilst kādam DPP laukam?
- 3.-5. diena: pirmie JSON eksporti no ERP sistēmas, izmantojot mūsu validatoru.
- 6.-8. diena: kļūdu novēršana (trūkstoši lauki, nekonsekventas kodēšanas).
- 9.-10. diena: pirmie DPP ir pieejami.
Divas nedēļas, nevis trīs mēneši. Galvenais posms ir kartēšanas darbseminārs - tajā tiek lemts par datu kvalitāti.
Kas var noiet greizi: visbiežāk sastopamās problēmas
Produktu pamatdati vairākās sistēmās: SAPsistēmā ir preču numuri, PIM sistēmā - attēli un mārketinga teksti, PLM sistēmā - detaļu saraksts. Nevienam nav vienota priekšstata. Risinājums: pirms projekta sākšanas noteikt, kura sistēma ir „patiesības avots” katram laukam.
Sertifikāti PDF formātā: piegādātāji iesniedz GOTS, OEKO-TEX vai REACH sertifikātus kā PDF skenējumus. Tas nav strukturēts datu avots. Risinājums: sertifikācijas iestādes arvien biežāk piedāvā API pieprasījumus (OEKO-TEX ir līderis, GOTS atpaliek). Vai arī: ievadiet datus manuāli, bet norādiet derīguma termiņu, lai DPP neparādītos sertifikāti, kuru derīguma termiņš ir beidzies.
Receptūras konfidencialitāte: īpaši kosmētikas, pārtikas un farmācijas nozarē - pilnā receptūra ir uzņēmuma noslēpums. Vai DPP tai jāpadara to publiski pieejamu? Risinājums: ESPR trīs līmeņu modelis. Publiski pieejama ir produktu kategorija, bet iestādes redz pilnu receptūru. Tas gandrīz nekad nav šķērslis, taču tas ir jānoskaidro jau agrīnā stadijā.
CO₂ dati, pamatojoties uz piegādātāju informāciju: jūsu piegādātājs norāda vidējo rādītāju visam savam produktu klāstam, nevis katrai partijai atsevišķi. Risinājums: pagaidām to pieņemt, bet ilgtermiņā pielāgot piegādātāju līgumus. ESPR prasa produktu specifiskus rādītājus, sākot no noteiktas dienas, taču pašreizējā prakse ir kompromiss.
Vietējās valodu versijas: jūsu ERP sistēmā ir tikai produktu nosaukumi vācu un angļu valodā. 27 ES valstīm jums ir nepieciešams vairāk. Risinājums: mašīntulkojums ar terminoloģijas datubāzi; par to mums ir atsevišķs raksts.
Jautājumi, kurus jums vajadzētu uzdot pirms projekta uzsākšanas
Pirms nosūtāt pieprasījumu piedāvājumu (RFP) trim piegādātājiem, atbildiet uz šiem jautājumiem iekšēji:
- Cik daudziem produktiem/preču numuriem ir jābūt DPP? (10, 10 000, 1 miljons?)
- Kādas sistēmas šobrīd glabā DPP nozīmīgos datus?
- Kura nodaļa pārvalda katru no šīm sistēmām?
- Vai jums ir ieguldījums vidusprogrammatūrā, kas būtu jāizmanto?
- Vai virs jūsu ERP sistēmas jau darbojas API slānis?
Atbildes noteiks, kurš no trim paraugiem jums ir piemērots. Un tās noteiks, vai projekts ilgs divas nedēļas vai sešus mēnešus.